---
description: 领域驱动分层结构
---

## 四层架构
领域驱动设计为了能够更好贴合业务进行落地，也经常会使用分层架构，这样能够更好的凸显领域模型。

传统的三层架构以数据库作为架构起点，我们会从数据库层面开始分析以及设计，但是 DDD 的重点不在数据库，而在领域模型，我们会将领域模型作为我们的分析基点，向上进行衍生。进而进行分层设计。


<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241214182023.png"/>

* User Interface 为用户界面层（或表示层），负责向用户显示信息和解释用户命令。这里指的用户
可以是另一个计算机系统，不一定是使用用户界面的人。也就是说，其实大部分的情况，后端向前
端展示信息，我们的前端也相当于我们的用户，后端则是暴漏接口。完整内容聚合操作。这里一般
代码中会写到装配器，控制器。以及我们的model，不过这里的model是对外暴漏的model。因为
我们的实体有可能不会直接对外暴漏，而装配器会对model进行模型转化，包括这里还会有转换过
后的模型。
* Application 为应用层，定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层
所负责的工作对业务来说意义重大，也是与其它系统的应用层进行交互的必要渠道。比如我们的线
程调度task，应用服务service等等。但是这里的service不是指的我们的具体的业务逻辑，而是指
代的与模型，也就是实体无关的业务逻辑。

* Domain为领域层（或模型层），负责表达业务概念，业务状态信息以及业务规则，也就是我们的
领域模型。这里特别强调，其实我们的四层架构的业务与我们的实体实际上是放在一起的。我们是
通过业务与实体来建立的一个完整的领域模型。一般我们的事件event、模型mpdel，包括模型中
的工厂类，领域服务类，对象Vo，实体，Entity，聚合，还有我们的领域服务，比如分页操作，都会放在这里。
* 基础设施层：为领域层提供持久化机制，为用户界面绘制屏幕组件，等等，基础设施层还能通过架构框架来支持四个层次间的交互模式。

## MVC 模式和 DCI 模式

<img src="https://wkq-img.oss-cn-chengdu.aliyuncs.com/20241214183049.png"/>


我们把用户的请求接入到我们的MVC当中的C,也就是我们的Controller当中,而我们的Controller会对用
户的请求进行URL匹配处理,并且我们会在我们的service处理业务,而处理业务过程中我们会用到实体,也
就是我们的Entity,对应的就是MVC中的model.并且最后我们返回的时候肯定会封装一个模型,最终我们将
会把这个模型返回,给到我们的前端。


## 五层架构

数据边界与行为边界不一致，领域对象高内聚、低耦合问题。


## 六边形架构
依赖倒置原则+单一职责原则。
:::tip
高层模块不应该过于依赖底层模块，两者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
:::
六边形架构完全摆脱了原本分层架构的束缚，将这个架构设置成了六边形。

适配器分为两种，主适配器 （Driving Adapter）以及次适配器（Driven Adapter）。

主适配器主要负责用户的访问，也就是从接受用户输入，调用用户端口并返回。

次适配器主要实现应用的出口端口，向外部工具执行操作，也就是 ES、MySQL、Redis、Email 工具等等这些，这些都是与第三方的交互，统称为应用出口。

